Load balancing

ordilov / 2022. 3. 31

단어 말 그대로 부하(Load)를 분산(Balancing)하는 것을 의미합니다. 병렬 처리 작업에서 일부 노드에게 작업이 몰려서 과부하가 생기는 걸 막아줍니다. 균등한 분배를 위한 알고리즘이 중요한 역할을 맡습니다.

알고리즘에는 크게 두 부류로 나뉩니다.

정적인 알고리즘은 노드의 상황에 관계 없이 정적으로 분배합니다.

• 해시 (Hash)
• 랜덤 (Random)
• 라운드 로빈 (Round Robin)
• 가중 라운드 로빈 (Weighted Round Robin)

해시 (Hash) : 해시 알고리즘을 활용

• 특정 IP는 해당하는 해시의 서버에만 요청합니다.
• 특정 서버에서 무거운 작업을 계속 요청하는 경우 같은 서버에 작업이 몰릴 수 있습니다.

라운드 로빈 (Round Robin) : CPU 스케줄링의 라운드 로빈 방식 활용

• 모두 균등한 횟수 만큼 작업을 수행합니다.
• 일률적으로 분산하기 때문에 효과적인 부하 분산을 기대하기 어렵습니다.

동적인 알고리즘은 현재 상황을 기준으로 분배하며, 노드의 상황을 알기 위해 추가적인 작업이 필요합니다.

• 최소 연결 (Least Connections)
• 최소 응답 시간 (Least Response Time)

최소 연결 (Least Connection) : 세션 수가 제일 적은 서버를 선택

• 부하 상태를 고려해서 분산합니다.
• 새로운 서버를 추가하는 경우 세션 수가 0이라 요청이 몰릴 수 있습니다.

로드 밸런싱을 위한 구성에는 master와 worker로 구성됩니다. master는 알고리즘을 통해 어느 worker가 작업을 할당하는 역할을 맡습니다.

여기서 master는 서버뿐만 아니라 클라이언트도 될 수 있습니다. 서버 측이 담당한다면 백엔드 서버 중 하나로서 담당하게 됩니다.

서버가 여러 대로 확장되었을 때 트래픽을 균등하게 분산시켜주는 역할을 맡습니다.

L2에서 스위치가 MAC 주소를 기반으로 처리할 서버에게 분산시켜줍니다. MAC 주소만 알고서 로드 밸런싱을 해야되기 때문에 같은 네트워크 안에 있어야하는 제약이 생깁니다. 이외에도 여러 제약이 있어 잘 사용하지 않습니다.

L4에서 TCP/UDP 포트 정보로 분산합니다. 데이터 안을 보지 않고 패킷 레벨에서만 진행해서 속도가 빠르고 효율이 높습니다. 사용자의 IP가 수시로 바뀌는 경우 연속적인 서비스 제공이 어렵습니다. L4 패킷에는 L3 정보에 해당하는 IP가 포함되어 다음 같은 기능들을 사용할 수 있습니다. 기본적인 방식은 클라이언트에서 들어온 source, destination IP를 변경해서 서버로 넘겨줍니다.

사설 IP 주소를 공인 IP 주소로 바꾸는데 필요한 주소 변환 서비스입니다. 이 과정을 통해 서버들은 각자 공인 IP 주소를 가질 필요가 없어집니다. 로드 밸런서에서 공인 IP를 갖고 들어온 요청을 NAT를 이용해 처리할 서버의 사설 IP로 변경하면 됩니다.

• 공인 IP 주소를 절약할 수 있습니다.
• 외부에서 요청 서버의 IP를 모르기 때문에 보안성이 올라갑니다.

보통 Inbound traffic 보다 Outbound traffic이 많기에 둘 모두 받는 경우 부하가 커집니다. 따라서 Outbound의 경우 로드 밸런서를 안 거치고 직접 클라이언트에게 전달하는 방법입니다.

L7에서 TCP/UDP + HTTP의 URI, FTP 파일명, 쿠키 정보 등을 바탕으로 분산합니다. L7까지 거치기 때문에 아래 계층보다 비용이 들지만 그만큼 다양한 정보로 분산이 가능해집니다. HTTP의 경우 로드밸런서는 header에 X-Forwarded-For, X-Forwarded-Proto 그리고 X-Forwarded-Port를 넣어 원래 요청에 대한 백엔드 정보를 제공합니다. HTTPS의 경우 암호화를 추가하는데 이때 SSL 처리를 로드밸런서에서 하느냐, 서버에서 하느냐의 차이를 둘 수 있습니다. 이외에도 로드 밸런서가 제공할 수 있는 기능입니다.

• 서비스 디스커버리

어떤 요청이 어느 서버로 가야하는지 로드 밸런서가 저장하고 관리할 수 있습니다.

• 헬스 체킹

서버 상태에 대한 체크를 할 수 있습니다.

• 장애 허용

특정 서버가 고장나도 다른 서버에서 요청을 대신해서 받을 수 있습니다.

• TLS 종료

로드 밸런서에서 TLS 처리를 담당하면 내부는 HTTP로 통신이 가능해집니다.

클라이언트가 서버에 요청 시 프록시 서버를 먼저 거치게 됩니다. 요청을 받게 되는 서버들은 클라이언트의 정보를 모르고 프록시 서버가 요청한 것만 알 수 있습니다. 회사 내부 인트라넷에 요청할 때 이런 방식이 쓰입니다.

클라이언트가 서버에 요청 시 리버스 프록시를 거치게 됩니다. 요청을 받은 서버들은 클라이언트의 정보를 알지만 클라이언트는 알 수 없습니다. 로드 밸랜서는 이 역할을 맡습니다.

서버를 분배하는 로드 밸런서에 문제가 생길 수 있기 때문에 로드 밸런서를 이중화하여 대비합니다. Active 상태와 Passive 상태로 구성합니다.

1. 이중화된 Load Balancer들은 서로 Health Check를 합니다.
2. Active가 동작하지 않으면 가상 IP(Virtual IP)는 Passive로 변경됩니다.
3. Passive가 Active로 변경되어 운영하게 됩니다.

로드 밸런서를 이중화해도 서비스가 많아지면 문제가 생길 여지가 많습니다. 특히 로드 밸런서가 해야 하는 기능이 많다는 건 장애가 생기면 대체가 힘들어지는 걸 의미합니다. 이걸 지원하기 위해 라이브러리가 로드 밸런싱을 내장하는 방법이 있습니다.

내장형 로드 밸런싱을 사용했을 때 문제점은 서버가 로드 밸런서를 사용할 수 있는 언어로 제한됩니다. 사이드카 프록시는 이를 대신해서 로드밸런서와 함께 서비스를 운영하는데, 컨테이너처럼 함꼐 실행할 수 있는 환경에서 이용합니다.

로드 밸런서로 분배할 때 서버가 로컬 세션을 사용하는 경우 어떻게 할지 고민이 필요합니다. 다시 요청했을 때 다른 서버에서 요청을 처리한다면 로컬 세션에 저장된 정보들을 사용할 수 없습니다. 따라서 분산 처리하는 경우 이를 대신해서 DB나 캐시 같은 공통으로 사용하는 저장소에 저장하는 것이 필요합니다.